Mal ein recht guter Artikel über die Dualcore/ Quadcore bzw. multithreaded entwicklung - und wie es weiter geht..
Hab den aus aktuellem Anlass mal wieder rausgekramt, da wir die Dual vs Quadcore Diskussion auch schon hatten - und mit Empire Total War grad auch ein recht gutes Spiel rauskam, welches nur EINEN KERN nutzt.
Der Quadcore setzt sich langsam durch und 6 bzw. 8 Kern CPUs liegen nicht mehr fern... das es so aber nicht so einfach weiter geht zeigt der artikel unten.
Sehr interessant finde ich:
- WinVista / Win7 unterstützen beide nicht mehr als 4 Cores, bzw. die Ultimate versionen supporten auch 8, nutzen aber wohl nur 4.
- Bei 8 Kernen wird im Privatanwender/Desktop/Workstation bereich laut AMD und Intel erstmal wieder Schluss sein, die manycore CPUS werden in Servern und im Professionellen bereich genutzt.
- Selbst 5 Jahre nach Einführung von HyperThreading und 2,5 Jahre nach Einführung der Dualcores sind viele Anwendungen, auch größere immernoch reine singlethreaded anwendungen. Dualcore hat sich durchgesetzt, doch selbst dort dauert die Optimierung an... Die Quadcore optimierung ist komplizierter, aufwendiger und nicht mit jedem Programm möglich.
Bisher war das kein Problem, weil die Quadcores im vergleich zum Single und Dualcore noch relativ hohe Taktraten halten konnten.. doch bei 6,8 oder many core CPUs wird man nicht die Taktraten erreichen die Dualcores bis dahin erreichen (4 ghz) - sondern eher bei der Hälfte liegen. Bei den Many Cores erstrecht.. bei 20, 40 oder 60 cores hat man vllt. noch 1ghz cores die wenig strom brauchen... und spätestens dann hat man bei einer singlethread anwendung ein problem - da deutlich weniger performance als 1 kern eines aktuell schnellen dual oder quadcores.
Zitat: (Quelle siehe unten)
Wenn "Netz Reporter" taub und blind sind.
Ein Witz!
Ey, kennst Du den schon? Sagt der Taube zu dem Blinden: "Ich hab gehört, WindowsVista kann nur mit bis zu 8 Kernen und läuft nur mit bis zu 2 Kernen optimal. Das hat mir der Ty Carlson auf CNet gesagt."
"You're going to see in excess of 8, 16, 64 and beyond processors on your client computer,"... WindowsVista on the other hand, is "designed to run on 1, 2, maybe 4 processors," (Ty Carlson; CNet)
Für den Blinden hat sich das dann so angehört:
Vista: Nicht mehr als vier Prozessorkerne möglich?
Microsofts Betriebssystem Windows könnte auf dem Weg zu immer mehr CPU-Cores nun offenbar zu einem Hindernis werden, ... (Quelle: Winfuture.de)
Planet3DNow hats schon vorher gewusst:
Eigentlich ist diese Erkenntnis, die Ty Carlson, Direktor für technische Strategie bei Microsoft, im Rahmen einer Podiumsdiskussion auf der Future-in-Review-Konferenz zum ersten Mal auch öffentlich verlauten ließ, nichts Neues.
Tja, da hat Mr. Carson ja einen dummen Fehler gemacht. Er hat laut ausgesprochen, was sowieso jeder wusste.
Die Erklärung liest sich für den belesenen Informatiker wie eine neue Wissenschaft. Microsoft hat offensichtlich eine neue Thread-Technologie eingeführt "das Deckeln".
Vier CPU-Kerne kann der Vista-Scheduler noch ganz gut mit Arbeit eindecken. Bei Systemen mit noch mehr Kernen fängt Windows dann an zu deckeln... (Quelle: Planet3dnow.de)
Daraufhin geht der Blinde in seine Selbsthilfegruppe und erzählt allen: "Linux ist besser als Windows. Bill Gates hats gesagt, ich habs genau gesehen!"
Klare Sache!
Viele Seiten haben das mittlerweile richtig gestellt (oder, doch auch erst, nachdem sie mal einen Text von jemanden gelesen hatten, der sich mit sowas auskennt).
Also: Der WindowsVista-Kern, ein direkter Nachfolger von WindowsNT unterstützt grundsätzlich bis zu 64 Kerne (Datacenter-Server). Schon zu WindowsXP-Professional-Zeiten hat jedoch Microsoft mit voller Absicht den Support für mehr als 2 Kerne limitiert. Dieses Limit soll es nun eigentlich nicht mehr geben (Vista Ultimate bis zu 8 Kerne, wobei das OS sich davon maximal 4 gönnt). Doch dies führt dazu, dass gerade das Betriebsystem selbst nicht mehr als einen, vielleicht zwei Kerne für sich beansprucht.
Wenn nun ein Intel "Polaris 2" mit bis zu 80 CPU-Kernen kommt, die jeder für sich weit weniger Leistung haben, als die aktuellen Prozessoren, aber alle zu sammen natürlich deutlich mehr, dann bekommt der WindowsNT-Kern ein Problem.
Man bekommt ihn vielleicht so hin gebogen, dass er auf 4 Kernen noch mitzieht, unter Umständen auch auf 8, danach muss aber ein komplettes Umdenken stattfinden. Und genau das hat Mr. Carlson gemeint.
So weit zur Schuld von Microsoft selbst. Andererseits ist die historisch gewachsene Single-Thread-Architektur mit Schuld. Sprich ein Programm, ein Thread. Das waren halt die 80er und 90er... Highlander war im Kino erfolgreich ("Es kann nur einen geben!" Warum eigentlich?), zum Zeitreisen benötigte man nur einen Flux-Kompensator und Matthew Broderick hat mit seinem Brotkasten das US-Militär hacken können.
Das Dilemma liegt in der Abarbeitung des Programmcodes. Mehrere Threads bedeutet mehreres zu parallelisieren.
Ich beschreib das ja immer gerne mit Kaffee kochen. Wen einer Kaffee kocht, tut er
1. Das Wasser in die Maschine
2. Kaffeefilter in den Filterhalter
3. Kaffee in den Filter
4. Kanne drunter stellen
5. Maschine an
Wenn nun zwei Prozessorkerne Kaffee kochen wollen, dann könnte das so aussehen
1. CPU1: Wasser + CPU2: Filter
2. CPU1: Kaffee + CPU2: Kanne
3. CPU1: Maschine an
Ah! Nur noch 3 Arbeitsschritte - sehr gut! Der Aufwand hat sich als um ca 30% gesenkt.
Mehr parallelisieren geht aber nicht. Schon eine dritte Kaffeekochende CPU würde in Schritt 1 nichts tun können. Denn die Kanne darunter stellen kann sie erst, wenn das Wasser in der Maschine ist, das Kaffeepulver erst einfüllen, wenn der Filter im Filterhalter ist. Und wenn sie die Maschine jetzt schon einschaltet, gibts ein Unglück. Ende der Thread-Zerlegung.
Ergo: Wir brauchen eine zweite Maschine und können dann bis zu 4 CPUs beschäftigen.
In jeder der Maschinen kochen wir dann nur halb so viel Kaffee.
Aber auch das hat ein totes Ende. Denn irgendwann kochen wir in jeder Maschine nicht einmal mehr eine Tasse und haben trotzdem 16 CPU-Kerne damit beschäftigt. Wir könnten natürlich einfach mehr Kaffee kochen, aber den braucht keiner!
Dieses simple Alltagsdilemma zeigt das Problem das JEDE Programmierung hat. Manchmal sind Abläufe vom Ergebnis eines anderen Ablaufs abhängig und irgendwann ist ein Grad der Arbeitsteilung erreicht, in dem sich ein Problem nicht weiter zerlegen lässt.
Unix, Linux und die Server
Schon tanzen die Linuxer wie die Inquisition ums Feuer und freuen sich, dass Linux das ja alles kann. Nein, tut es nicht, es macht es nur besser. Im Serverbereich gibt es viele Dienste synchron am Laufen zu halten. Ein Webserver selbst kann bspw. schön parallelisieren. Sehr einfache Aufgaben, welche selten von einander abhänigig sind und vieltausendmal in kurzer Zeit wiederholt werden. Perfekt! Darum hat sich auch im Serverbereich deutlich Multi-Threading durchgesetzt. Ein kleiner Server hat heute schon 4 Kerne.
Tatsächlich hat die Herkunft aus dem Serversegment Vorteile für Linux. Seitens des Kernels muss man sich weit weniger Gedanken um 80-Cores machen, als Microsoft. Microsoft darf sich wahrscheinlich einen komplett neuen Kern stricken.
Doch eines kann Linux wie Windows auf die Füße fallen: Was wenn die Anwendungsentwicklung nicht mit zieht? Sprich ein Programm vielleicht auch älteren Datums, benutzt nur einen Thread. Dann wird es auch nur auf einem der 80 Kerne laufen. Wie erwähnt ist ein einzelner Kern deutlich langsamer als die meisten heute verfügbaren Single-Cores. Diese werden dann schön gemächlich auf ihrem Kern laufen es sei denn man virtualisiert!
Virtualisierung sinnvoll eingesetzt
Und da kommt nun Virtualisierung ins Spiel. Heute bedeutet Virtualisierung hauptsächlich noch, bei einem Multi-Kern-System einen Kern zu verwenden, um ein zweites Betriebsystem mit guter Peformance parallel zu starten.
Morgen könnte die Sach auch so laufen, dass einem Betriebsystem auf einem 80-Kerner ein Prozessor mit nur 4 Kernen "vorgegaukelt" wird. Die dafür notwendige automatische "Threadzerlegung in Hardware" jeodch ist eine Wissenschaft für sich. Woher soll die Virtualisierungsmaschine wissen, dass das, was da raus kommt mal Kaffee werden soll? Willkommen in der Welt der Skalararchitekturen...
So ist es und so sollte es sein
Doch niemand bringt den Anwendern das Dilemma bei. Ganz nach dem mittelalterlichen "Die Erde ist eine Scheibe"-Konzept wird dem Anwender erklärt, dass Microsoft "Schuld" sei. Man kann den Redmonder Riesen durchaus da eine Teilschuld nachweisen, doch Fakt ist: Es müssen alle Softwarehersteller mitziehen.
Kaum jemand spricht die Probleme direkt an und erklärt warum ein 80-Core warscheinlich nicht "der Hammer" wird (Weil man keine 80 Leute braucht um ne Kanne Kaffee zu kochen!).
Fakten
Sowohl Intel, wie auch AMD haben durch die Blume breits gesagt, das bei Octa-Cores (8 Kerne) erst einmal wieder Schluss sein wird mit den Desktop-Multi-Cores. Schon bei aktuellen Quad-Cores hält sich der Mehrnutzen in Grenzen (aktuell im Otto-Normalanwender-Bereich gleich Null).
Seitens AMD wird schon seit geraumer Zeit an o.g. Virtualisierung geforscht. Schon beim Quad-Core herrscht Optimierungsbedarf!
Gerade hat sich die Softwarebranche zu halbwegs erträglichem Support für DualCores durchgerungen. Und selbst hier sind es die Vorreiter auf dem Desktopsegment, die Spiele, welche am meisten davon profitieren.
Packprogramme, Codecs, Videorenderer, Bildbearbeiter usw. lernen nur sehr allmählich mit mehr als einem Kern zu hantieren. Irgendwann wird ein Dual-Core vielleicht voraussetzung, damit ein Programm überhaupt läuft. Doch solche Programme gibt es aktuell praktisch nicht.
Wir haben das Jahr 2007 - Zweieinhalb Jahre nach der Einführung der DualCores im Desktopbereich und fünf Jahre nach Intels Hyperthreading. Es wird noch mindestens 2 Jahre dauern, bis DualCores auf breiter Front unterstützt werden. Die Anpassung der Software auf Quad-Cores wird sogar noch schwieriger (und ineffizienter). Über den Sinn und Unsinn von Octa-Cores können wir uns vielleicht 2012 unterhalten. Bis dahin kräht kein Hahn mehr nach WindowsVista und wenn alles gut geht, nutzen wir dann alle Linux und lachen über die heutige Meldung.
Quelle:
http://www.orthy.de/index.php?option=com…=4719&Itemid=38 
MastersForum »
Allgemein »
TechTreff »
Zitat
Original von Attila
Ich weiß ja nicht wie die intern programmiert sind, aber ich würde das dann so machen: Ein Thread macht intern einen Server auf und die KI loggt sich in einem (wie auch immer gearteten) Pseudonetzwerk wie ein menschlicher MP Spieler in das Spiel ein. Ab da kann jede CPU/KI tun und lassen wie sie will und gibt Kommandos an den "Server"/"Host". Das geht natürlich besser wenn jede KI ihre eigene CPU hat, als wenn sich alle die Rechenzeit einer CPU teilen. 
